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[57] ABSTRACT 

The invention is a debugger which is part of the operat- 
ing system of a multi-programmable digital data proces- 
sor with virtual memory. The debugger can identify 
and correct faults in an embedded operating system of a 
multi-programmable digital data processor having 
hardware-controlled process exchange. The debugger 
is capable of suspending and effectively restarting pro- 
cesses in a primary or second central processing unit, as 
well as selectively accessing, reading, and/or modifying 
data at real or virtual memory locations. Further, the 
debugger can look ahead, using a next instruction pre- 
diction function, and determine the location of the next- 
to-be executed instruction. The debugger can then re- 
place the previous breakpoint with the instruction the 
break point had originally replaced, and put the break- 
point after the next-to-be executed instruction. The 
debugger is also capable of simulating the local execu- 
tion of a replaced instruction and restarting suspended 
processes. In this way the debugger can be used in 
single-step fashion to cause process suspension after 
every instruction in a sequence of code. 

28 Claims, 4 Drawing Sheets 
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uler element, a central processing unit, and a debugger 
OPERATING SYSTEM DEBUGGER element. The first dement, the memory element, in- 

cludes addressable locations for storing process code 
BACKGROUND OF THE INVENTION signals associated with each of one or more processes 

This invention is directed to toe field of digital data 5 residing on the system The process code signals of each 
processing and, more particularly, to the field oflocaliz- Process * cludc representative of at least one of 
mg and correcting faults in the operation of multipro- instructions, data, and state values associated with the 
grammed digital data processing systems. process. f . ^ .„ t . ... 

A conventional computer system operates under the By way of example, in the illustrated embodiment, 
control of a collection of programs known as an "oper- 10 the memory element includes the main memory, as well 
ating system" which provides an interface between as its cache memory and processor registers. The pro- 
machine hardware of the host computer and user pro- cess code signals associated with each process may 
grams being processed by that computer. An important include, for example, instructions which are to be exe- 
aapect of the interface is the control of allocation of cuted by the process, along with the process control 
physical computer resources, including the program 13 information, including register values, program counter 
and data stores, the central processing unit, and the information, and other state information, 
input/output devices. The breakpoint setting element replaces those signals 

Among the various types of operating systems pro* in the memory register element representative of a se- 
vided in the art is the so-called ^ulttprbgrammed" lected instruction with signals representative of a se- 
operating system. In such a system, the host computer 20 lected interrupt instruction. For example, in the illus- 
concurrendy maintains several user programs in main trated embodiment, the breakpoint setting element can 
storage and allocates the central processor to each of be used to replace a given instruction, e.g. t a register 
those programs on an alternating basis. More particu- increment instruction, maintained in the user or operat- 
larly, as the host computer runs, its operating system m $ system code with an interrupt-invoking instruction, 
dedicates system resources to each process for a brief " & ^ OQC for causing a system fault 
period of time, termed a "time slice." In carrying out The aforementioned scheduler element schedules one 
this task, the operating system must save state informa- of ^ residentt waiting processes for execution during a 
tion for each process awaiting execution, while storing time interval That is, the element makes one 

in the registers and cache state information for the pro- of p rocesscs active. 

cess which is presently active. » roccs3in ^ ^ b coup ied to the memory 

While on many m^iunei the swappmg of processes is ^ deme ^ t md to the ^eduXcr element for nor- 

done entirely in software, on some machines, eg., the ^ cxecutillg code associated with the scheduled 

^T^T^.T^^Jl mJT Process continuously during the designated time inter- 

signee hereof, Prune : Compute^ Inc. of Natick, Mass., P processing unit can also include an 

orccess exchange is done in hardware or, more spccifi- 35 \ ' y , . . 4 

Su^mS element for executing the aforementioned interrupt 

Wn^erenc7to ano^pect of operation, com- ^<*°? to P™*« a * ! ?*f ^ 
outers may have an architec^wmch^vides an . ™J f>"*8« f T" 1 •* cdvd * sus ^ P r °^ 
^ernbedded- operating system. In such aiystem, the m * of actehtel, or active, process by the central 
S^ KS e-g, user programs, in- 40 Processing unit and permits selective access to locations 
Z^^of^ oper^ti^Stem of said memory unit for modifying or outputting values 
code. WimnTthese systems, each user process executes of signals stored in those accessed locations A Simula- 
a procedure call whenever it desires to execute a por- tion element is provided forgenerating signals represen- 
tion of the shared operating system code. Such a proce- Native of simulation code That code, which is relocata- 
durecallb identical to that used by the user process to 45 ble, simulates the action of the replaced instruction. The 
execute its own subroutines, simulation element itself includes an element for modi- 
With this background, an object of the invention is to ft™** ^thin the memory means, process code associ- 
provide an improved digital data processing system. with the suspended process. Specifically, the eie- 
More particularly, an object of the invention is to pro- ment modifies the code to include the simulation code, 
vide a digital data processing system with improved 50 The debugger element further includes a restart de- 
fault detecting capabilities. ment for reactivating the suspended process for execu- 

Further, an object of the invention is to provide a tion of at least said simulation code, 
mechanism for identifying and correcting faults in an In another aspect, the invention provides a processor 
embedded operating system of mdtiprogrammable dig- of the type described above wherein the debugger ele- 
ital data processor having hardware-controlled process 55 ment includes an element responsive to the selected 
exchange. interrupt signal for inhibiting the scheduling element 
Still further, an object of the invention is to provide from scheduling any other process for execution. Fur- 
an improved system of the type described above in ther according to this aspect of the invention, the restart 
which process operation can be suspended at designated element includes an element for re-enabling the schedul- 
points in the instruction sequence. 60 ing element to schedule for execution said other pro- 
Other objects of the invention are evident in the dis- cesses, 
cussioo which follows. In ve t another aspect of the invention, there is pro- 
vided a digital data processor of the type described 
SUMMARY OF THE INVENTION above including a fault handler element for generating 
The aforementioned objects are attained by the in- 65 and storing, in said memory element, stack frame signals 
vention which provides, in one aspect, an improved representative of a state of the scheduled process imme- 
multiprogrammable digital data processor including a diately subsequent to execution of the debug interrupt 
memory element, a breakpoint setting element, a sched- instruction. The fault handler element further includes 
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an dement for generating a debugger start-up signal, 
while the debugger element includes an element respon- 
sive to that signal for commencing operation. 

Another aspect of the invention provides a process as 
described above wherein the debugger element includes 5 
a single-step element for reinstituting 8 replaced instruc- 
tion and for replacing a next instruction with the se- 
lected interrupt instruction. By way of example, in the 
illustrated embodiment, the single-step element may be 
invoked to cause process suspension after every instruc- 10 
noa in a sequence of code. 

Accordingly to still another aspect of the invention, 
the single-step element can include an element for pre* 
dieting the location of the next instruction to be exe- 
cuted within the memory element 15 

Still further, an aspect of the invention provides the 
improvement wherein the next instruction prediction 
element includes an element for simulating local execu- 
tion of the replaced instruction. 

Still further aspects of the invention are directed to 20 
the method of operation of a debugger of the type de- 
scribed above. 

The above aspects, as well as others, are evident in 
the description which follows. 

BRIEF DESCRIPTION OF THE DRAWINGS 23 

A more complete understanding of the invention is 
provided by the drawings, in which: 

FIG. 1 depicts a processing environment of the type 
in which the invention is practiced. 30 

FIG. 2 depicts an architecture of a debugging appara- 
tus constructed in accord with a preferred practice of 
the invention. 

FIG. 3 presents an upper-level block functional dia- 
gram of a debugger constructed according to a pre- ^ 
ferred practice of the invention, 

FIG. 4 depicts an operational sequence of a preferred 
breakpoint handling process. 

FIGS. 5A, 5B, and 5C depict the modification of user 
or system code effected by a debugger operating in ^ 
accord with a preferred practice of the invention. 

FIG. 6 depicts a user process stack frame sequence 
effected during operation of a preferred breakpoint 
sequence. 

FIG. 7 depicts a preferred sequence utilized in per- 45 
forming next instruction prediction. 

FIG. 8 depicts a dual processor system including a 
debugger configured in accord with one preferred prac- 
tice of the invention. 

DESCRIPTION OF THE ILLUSTRATED 50 
EMBODIMENT 

I. General Description 

The process of isolating and correcting mistakes in 
computer programs is known as debugging, while the 55 
apparatus which facilitates that action is known as a 
debugger. Such apparatus typically features the ability 
to examine and modify either the main memory or the 
registers of the host computer system. 

An essential requirement of any debugger is that it 60 
provide a breakpoint facility, i.e., the capability to tem- 
porarily suspend process execution at a specified in- 
struction location. For example, it may be discovered 
that a particular user process fails repeatedly upon in- 
voking the operating system page fault sequence. 63 

In order to locate the exact cause of such error, the 
operator may utilize a debugger constructed in accord 
with the invention to identify the state of the system at 



4 

the time the page fault sequence is invoked. Such identi- 
fication is specifically carried out by using the debugger 
to set a breakpoint, for example, at the address of the 
first instruction of the page fault sequence. Upon exe- 
cuting the breakpointed instruction, the system will 
suspend the state of the executing process and transfer 
control to the debugger to permit the operator to inter- 
rogate and modify system values. 

In providing breakpointing, a debugger constructed 
in accord with the invention includes a mechanism for 
overwriting an existing instruction with a special inter- 
rupt instruction, i.e., one which causes a machine fault 
or trap upon execution by the central processing unit A 
debugger constructed in accord with the invention also 
provides a mechanism for executing a breakpointed 
instruction without deleting the breakpoint — that is, 
without deleting the substituted interrupt instruction. 
Unlike various prior art systems, the illustrated debug- 
ger provides such capability without hardware support. 

Those skilled in the art will appreciate the inherent 
difficulties presented when attempting to implement a 
debugger on a machine having an embedded operating 
system. Generally, such difficulties are understood to 
arise because multiple processes may execute a break- 
pointed section of code at the same time. For example, 
if a first process executes a breakpoint and reinstitutes 
the original breakpointed instruction, a second process 
executing that same code might inadvertently cause 
execution of the reinstituted instruction code without 
invoking the debugger. This would result, of course, 
because the breakpoint had previously been remove- 
d — albeit temporarily— by the first process. This type of 
erroneous behavior, i.e., that occurring where the order 
of scheduling two processes affects the results, is re- 
ferred to as a race condition. 

A debugger constructed in accord with the invention 
permits breakpointing and avoids race conditions 
within embedded operating system code through utili- 
zation of a debugger element which is independent of 
operating system code and which executes at the high- 
est priority provided by the system. Such a debugger 
relies on the breakpointed process, i.e., the user process 
which executed the breakpoint interrupt, to execute 
code which will simulate the effect of executing the 
original breakpointed instruction. 

II. The Data Processing Environment 

FIG. 1 depicts a digital data processing system pro- 
viding an environment for practice of the invention. 
The system 10 is comprised of a system console 12, a 
user console 14, digital computer 16, secondary, perma- 
nent storage media 18, and communications control 
device 20. The digital computer 16 includes a processor 
22, an input/output control section 24, and volatile 
storage 26. Digital computer 16 is coupled with con- 
soles 12, 14 by way of bus 28, while being coupled with 
storage media 18 and control 20 by way of lines 30 and 
32, respectively. 

In the illustrated embodiment, system console 12 is a 
dedicated terminal configured for running high-priority 
system functions, e.g., system "boots" for initiating 
computer operation. User console 14 represents any of 
numerous user terminals which may be connected to 
the computer 16 for running both general and high-pri- 
ority tasks. Permanent storage device 18 represents any 
of one or more disk drives, tape drives, and other per- 
manent storage apparatus which are well known in the 
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art. Control element 20 represents standard communica* will henceforth be identified as the BRKPT instruction, 

tions device including, for example, a network inter- A preferred software embodiment of the system fault 

fac^ handler 47 is provided in Appendix C (available in the 

Apart from the improvements described herein, digi- application fBe history) at pp. 681-683. 
tal computer 16, including processor 22, input/output 5 FIG. 3 depicts a configuration for debugger 48 con- 
control 24* and volatile memory 26, may be of conven- structed according to a preferred practice of the inven- 
tional construction, configuration, and operation. Pref- tion. In particular, the debugger 48 includes a command 
erably, the computer 16 operates with an embedded dispatch element 62, a command line handling element 
operating system and includes a microcode-based pro- 64, a fault handling element 66, a start-up element 68, a 
cess exchange mechanism. A Preferred system for use 10 console interface logic element 70, an output format 
in construction and operation of the illustrated embodi- element 72, a command logic element 74, and a load 
ment of the invention is the Series 50 computer manu- map element 76. The command dispatch element 62 
factured by the assignee hereof, prime Computer, Inc., communicates with each of elements 64, 66, and 68 via 
of Natick, Mass., operating with version 20,1 of the lines 78, 80, and 82 respectively. The handler 64 trans- 
PRIMOS (Trade Mark of Prime Computer, Inc., Na- 15 fers signals with the console interface 70 on line 86, 
tick, Mass.) operating system. while that latter element transfers signals with the for- 

FIG. 2 illustrates a configuration for a digital com- mat element 72 via line 88, as shown. Communications 

puter 16 operating in accord with a preferred practice between the command logic 74 and each of elements 62, 

of the invention. As shown, the volatile storage area 26 72, and 76 are carried out over lines 90, 92, and 94, 

includes random access memory unit 36, cache memory 20 respectively. 

38, and registers 40. The computer 16 also includes The start-up element 68 initiates operation of the 

scheduling and exchange element 44, central processing debugger 48. The element 68 may be invoked by the 

unit (CPU) 46, system fault handler 47, and debugger operating system of the host computer upon execution 

48. Debug element 48 includes breakpoint element 42 of a breakpoint instruction, upon interruption by the 

and debug process 49. 25 system console, or upon the execution of page faults. 

Bus line 50 provides communication between the Generally, the start-up element provides functionality 

debugger 48 and the storage area 26, while signal trans- for saving information regarding the state of the user 

fers between the storage area 26 and the scheduler/ex- process from which the debugger was invoked, and for 

changer 44 are handled along line 52. Transfers between notifying the command dispatch element 62 to begin 

the CPU 46 and each of the storage area 26, the debug- W operation of the debugger process. The start-up element 

ger 48, and the scheduler/exchanger 44 are carried out is also responsible for suspending process execution of a 

along lines 54, 56, and 58, respectively. Communica- second, or "slave," processor of a dual processor system 

tions between the debug process 49 and the breakpoint prior to initiating the debugger 48. 

element arc effected along communications path 59, as In addition to being operable on single processor 

shown. The scheduler/exchanger 44 communicates 35 computer systems of the type shown in FIGS. 1 and 2, 

with the debugger 48 on line 60, as shown, while that the illustrated debugger 48 is also operable for execu- 

latter unit communicates with the system console via tion on host computer systems having dual processors, 

line 61. Path 51 provides a communications link be- e.g., the Model 850 system of the Series 50 computers 

tween CPU 46 and system fault handler 47. manufactured by the assignee hereof, Prime Computer, 

In a preferred embodiment, central processing unit 40 Inc. The Model 850 system is a tightly coupled shared 
46, scheduling-exchange element 44, and volatile stor- memory dual processor computer system in which pro- 
age area 26, including random access memory 36, cache cesses can execute on either processor. However, only 
memory 38, and registers 40, are provided as standard the "master" processor can execute input/output in- 
components of the assignee's aforementioned Series 50 structions, while the "slave" processor cannot. Accord- 
computer. The construction and interaction of the 45 ingly, the illustrated debugger 48 executes in conjunc- 
breakpoint and debugger elements 42, 48 with that com- tion with the master processor, while issuing an instruc- 
puter are discussed below. tion sequence to suspend further processing by the slave 

The system fault handler 47 used in a preferred em- processor. In this regard, it will be noted that a user 

bodiment of the invention is provided as a standard process executing on either processor may execute 

component of the operating system of the aforemen- 50 breakpointed code which initiates action of the debug- 

tioned Series 50 computer. The fault handler 47 is in- ger 48. 

voked by action of the CPU 46, for example, when code A dual processor arrangement of the type referred to 

executing therein cannot complete a task without spe- above is shown in FIG, 8. In particular, a master central 

cial help. In this regard, see chapter 10 of the document processing unit 238 and a slave central processing unit 

DO&A11-LLA System Architecture Guide Revision 19.4. 55 240 are coupled for communication with a debugger 

filed herewith as Appendix A (available in the applica- element 4B by paths 242 and 244. An additional ele- 

tion file history). By way of example, the fault handler ment, the front stop element 246 is also coupled with the 

47 responds to page fault— which occurs when the CPU slave CPU 240 and the debugger 48 via path 244. 

46 attempts to reference memory not currently resident In order to synchronize operation on the illustrated 

in main memory 26— by invoking a routine to read 60 dual processor system, the debugger 48 employs a 

further data from the disk drive 18. "front stop" element 46 to inhibit operation of the slave 

In the illustrated embodiment, the system fault han- processor during execution of the debugger process on 

dler 47 is arranged for responding to the execution of a the master processor. In a preferred embodiment, the 

debug fault instruction by the CPU 46 for invoking a front stop element 46 comprises an instruction sequence 

debug start-up element, discussed below. The instruc- 65 which places the slave processor 240 in a continuous 

tion chosen for initiating a debug fault has no instruc- loop. Preferably, the element 46 is configured as the 

tion mnemonic since architecturally it is classified as an highest priority process capable of executing on the 

illegal instruction. This instruction, opcode 1703 octal, slave CPU 240, thereby preventing any other processes 
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from being scheduled for execution by that processor 
240 during execution of the debugger process 49 on the 
master CPU 238. 

A preferred software embodiment of the start-up 
element is provided in Appendix C (available in the 
application file history) at pp. 250-254. 

The dispatcher 62 serves as the main execution loop 
for the debugger 48. Its role is to read in a command 
line, to determine if a valid command has been entered, 
and to transfer control to appropriate elements for pro- 10 
cessing each given command. Before executing the 
aforementioned processing loop, the dispatcher 62 de- 
termines how the debugger was invoked, e.g., as a result 
of a breakpoint or system console command. If invoked 
as a result of a breakpoint or single step, an update 15 
routine is called to update breakpoint tables and decide 
whether to enter debugger command environment or, 
simply, to return to the host computer operating system. 

A preferred software embodiment of the dispatcher 
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placing a normal operating system instruction with a 
fault instruction, specifically the debugger interrupt 
instruction, BRKPT. For example, an exemplary user 
process (Le., a process other than the debugger process 
49) may be configured to execute code as follows: 



LDA 2000 
A1A 

ST A 2002 



(stored at address 4010) 
(stored «t address 4012) 
(stored at address 4014) 



where, the LDA instruction loads the A register with 
the value stored at address 2000; the A1A instruction 
calls for incrementing the value stored in the A register 
by one; and the STA instruction calls for storing the 
value of the A register at address 2002. 

The illustrated system permits the operator to set 
breakpoints at points in the operating system code, e.g., 



that presented in FIG. 5A, through joint action of the 

62 is provided in Appendix C (available to the applica- 20 debugger 48, including breakpoint element 4Z 



tion file history) pp. 281-294. 

The command logic 74 contains routines that perform 
the specific functions requested from the debugger 
command environment All such routines have logic to 
parse the tokens remaining in the command line read in 25 
by the dispatcher 62. 

The debugger 48 employs the command line handler 
64 and system console interface 70 to read from and 
write to the system console 12. The command line han- 
dler employs codes to support echoing, buffering, erase 30 
and kill characters, XON-XOFF, and quit handling. In 
order to permit the later two functions, the interface 70 
continually polls the console 12 for input 

A preferred software embodiment of the command 
line handler 64 is provided in Appendix C (available in 35 1' 
the application file history) at pp. 766-769, and pp. 
197-200, while a preferred software embodiment of the 
system console interface 70 is provided in Appendix C 
(available in the application file history) at pp. 102*107. 

Insofar as a debugger 48 constructed in accord with a 40 
preferred embodiment of the invention does not rely on 
services provided by the operating system of the host 
computer 16, the debugger 48 must have its own fault 
handler 66. This fault handler 66 is to be considered 
distinct from the host computer operating system fault 45 
handler 47 referred to above. The debugger fault han- 
dler 66 prevents the debugger 48 from losing control of 
the central processing unit to the operating system of 
the host computer. To handle faults that occur while 
the debugger 48 is operating, a separate fault table is 50 
provided. This fault table causes control to pass to fault 
handler 66 whenever a fault is detected. Upon invoca- 
tion, the primary job of this fault handler is to print 
error messages regarding the fault and to return control 
to the debugger 48. A preferred software embodiment 
of the fault handler 66 is provided in Appendix C (avail- 
able in the application file history) at pp. 231-234. 

Preferred software instruction sequences for the for- 
mat element 72 are provided in Appendix C (available 
in the application file history) at pp. 416-444 and pp. 
766-769, while a preferred instruction sequence for the 
load map element 76 is provided in Appendix C (avail- 
able in the application file history) at pp. 456-470 and 
pp. 479-483. 



55 



60 



III. Setting Breakpoints 

An operating system debugger 48 constructed in 
accord with the invention executes breakpoints by re- 



65 



FIG. 5B ( element 214, illustrates the effect of setting 
a breakpoint in the aforementioned exemplary code. 
Particularly, the modified operating system code shown 
in FIG. 5B includes the original "LDA 2000" instruc- 
tion at address 4010, as well as the original "STA 2002" 
instruction at address 4014. The operating system code 
212 also includes a debugger interrupt signal "BRKPT" 
stored at the address where the original increment in- 
struction, "A1A W , once resided. 

The breakpoint element 42 is responsive to com- 
mands^ 




42^^B^cifiemaWm8^e€n, i.e., BRKPT. The 
original— now breakpointed— instruction is saved for 
use in generating the simulated code discussed below. 

If an attempt is made to set a breakpoint at an instruc- 
tion not resident in RAM, the breakpoint element 42 
acts in combination with the debugger 48 to monitor the 
vqla ijleimeira?3^ 
M t^ged i n" t>y^cjj j^ 
lellstSracalS^ 

c od i||^j^^ 



A preferred software embodiment of the breakpoint 
element 42 is provided in Appendix C (available in the 
application file history) at pp. 133-145, 355-359, 
390-395, and 798-857. A preferred software embodi- 
ment of the mechanism for flagging breakpoints on 
nonresident pages is provided in Appendix C (available 
in the application file history) at pp. 552-563 and pp. 
512-519. 

At the time a breakpoint is set, the breakpoint element 
42 constructs a relocatable code sequence for execution 
by the user process. This relocatable code is stored in 
shared memory. In a preferred embodiment, the break- 
point element 42 creates the relocatable code from a 
template selected in accord with the type of the break- 
pointed instruction. Next, the element 42 and the debug- 
ger process 49 complete the template based on the spe- 
cific type of the breakpointed instruction. In this man- 
ner, the debugger 48 tailors a simulated code sequence 
which will perform the same operation that the break- 
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pointed instruction would have performed had it not debugger wr^J 
been removed in favor of the interrupt instruction eg., the field 1 



10 

instructions into each labeled 
5MREF— IND—DISP. 



field, 



MEMREF.TEMPLATE 

RRST 

MEMREF_EAXB_DISP 

EAXB 



MEMREF_EAL_DISP 



MEMR£F_IND_D ESP 



MEMREF_INST_DISP 



LDA % 

STL 

BSZ 

LDA 

TAX 
RRST 

P 

BSZ 



NOP 
STA 



TKA 
STA 
LDA 
PRTN 

MEMREF_JLENGTH EQU 



EQU * 

SB% +STARTUP_RSAV_AREA,* 

Ensure codex registers we setup. 
EQU •MEMREF_TEM PLATE 
SB* + STARTUP_B ASE REG, • 

Start with tee reg vilue if not reg, 

trap, else LDA, tab sequence. 
EQU •-MEMREP_TEMPLATE 
SB% + STARTUP_B ASE_REG 

Overwrite this instruction with an 

EAL if not reg trap. 
SB% + STARTUP_TEMP 

Address of operand, ilmost. 
EQU •*MEMREF_ TEMPLATE 
INDIRECT_CODE_LENOTH 

One word indirection code. 
SB% + STARTUP_FAULT_KE YS, • 

Restore keys. 

SB% +STARTUP__RSAV AREA* 

EQU *-MEMREF_TEMPLATE 



The simulated instruction put here may 
be either I or 2 words long. 



SB% + STARTUP __TE M P 

Need to use the A reg in order to save 
and return the value of the keys. 

SB% + STARTUP F AULT_ KEYS, » 

SB% + STARTUP_TEMP 

»-MEMREF_TEMPLATE 



BRKPT. The table below is utilized by breakpoint clement 42 

A preferred template used to build simulated code for 35 to fill in empty locations of the template at label MEM* 

a majority of memory reference instructions is shown REF—IND— DISP. Specifically, the table contains the 

below. The sequence is written with the instruction set code needed to achieve one word indirection. 



rNDIRECT_TAB NOP 




Direct. 


NOP 






NOP 






NOP 






NOP 






INDIRECT_CODE LENGTH 


EQU * INDIRECT_TAB 




LDA% 


SBft +STARTUP_TEMP,* 


Indirect 


STA% 


SB% + STARTUP^ .TEMP + 1 




NOP 






TXA 




Posttndexed 


ADD% 


SBtf> +3TARTUP_TEMP ( * 




STA% 


3B% + STARTUP_TEMP + 1 




LDA% 


SB%+STARTUP_TEMP ( * 


Preindexed 


STA* 


SB% + STARTUP— TEMP + 1 




NOP 







of the aforementioned Series 50 computers. Two docu- 
ments entitled DOC9414-ILA Instruction Sets Guide 
Revision 19.4 and UPD9414-X5A Instruction Sets Update 
Revision 20. 1 providing a complete description of the 
instruction set are filed herewith as Appendix B (avail- 
able in the application file history). The template is used 
in constructing all memory reference instructions of the 
aforementioned Series 50 computers, excepting those 
listed in Appendix C (available in the application file 
history), pp. 851-853. In completing the template, the 



Those skilled in the art will appreciate that a template 
of the type shown above for memory reference instruc- 

55 tions is constructed to ensure that all references to code, 
including that not presently resident in main memory 
36, are computed by the user process as it executes the 
relocatable code. Specifically, for example, the debug- 
ger 49 relies upon the operating system of the host 

GO computer to access non-resident memory. 

A preferred template for use in generating simulated 
code for jump instructions is as follows: 



JUMPS_TEMPLATE 



JUMP_EAXB_DISP 



EQU • 

RRST SB% + STARTUP_RSAV AREA,* 

Ensure index registers are setup. 
EQU *-JUMPS__ TEMPLATE 

Start with base reg value if not reg 
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-continued 







trap, else Ida. tab sequence. 




EAXB 


SB% +STARTUP_BASE REG,* 


JUMP_EAL_DISP 


EQU 


*-JUMPS_TEMPLATE 




Overwrite this instruction with 






an eal if act reg. trmp. 




LDA% 


SB% +STARTUP_BASE_REG 




STL 


SB% + STARTUP_TEMP 






Address of operand. 






Almost 


JUMP_1ND_DISP 


EQU 


♦^UMPS_TEMPLATE 




BSZ 


INDIRECT_CODE_LENGTH 






One word indirection code. 




LDL 


SB% +STARTUP_TEMP 






Pickup operand sddress. 




STLR 


XB 






Save location of dest for J ST. 


rUMP_JST_ADD 


EQU 


* -JUMPS ..TEMPLATE 




1AB 






AtA 






UB 








Add 1 to the destination to make 






executioa start past the return 






address (JST only). 




STL 


SB%+STARTUP_FREV_PC,* 






Make code jump to new destination. 




LDL 


SB% +STARTUP_BRKPT_ADDR 






Determme return location. 




IAB 




JUMP__ADD_DISP 


EQU 


MUMPS_TEMPLATE 




BSZ 


1 






Replaced by either AtA or A2A. 




IAB 






STL 


SB% +STARTUP_TEMP 






Now we have the return location. 


JUMF_JST_SEQ 


EQU 


♦-JUMPS_TEMPLATE 


LDA% 


SB% +STARTUP_TEMP+ 1 






These 2 instntctioos are only for JSTa. 






Otherwise they are NOP*ed. 




STA% 


XB% 




RRST 


SB* + STARTUP_RSAV_AREA,« 






Restore registers. 


JUMP_LOAD-DlSP 


EQU 


* - fUMPS TEMPLATE 




BSZ 


2 






Replaced by NOPs or a load 




PRTN 




JUMPS_LENOTH 


EQU 


•-JUMPS TEMPLATE 



FIG. 5C illustrates simulated code generated by the 
debugger 48. In the illustration, the simulated code 216 
provides, specifically, a relocatable instruction se- 
quence for simulating action of the break pointed in- 
struction **A1A". The content of the sequence 216 may 45 
best be understood with reference to the state of the 
user process at the time the sequence is executed. In this 
regard, attention is directed to FIGS. 4 and 6. 

FIG. 4 depicts a sequence of steps carried out within 
digital computer 16 operating under control of host SO 
operating system code and with a debugger 48 con- 
structed in accord with the invention. The sequence 
begins with the execution of breakpointed code of the 
type shown in FIG. 5B. At the outset, the processor 22 
executes the LDA instruction stored at address 4010. 35 
Subsequendy,, at step 188, the processor 22 executes the 
interrupt instruction BRKPT stored at address 4012. 
See FIG. 4, element 188. At the time of execution of the 
breakpointed instruction, the user process stack in- 
cludes only one frame. The state of the system vis-a-vis 60 
stack frame content is shown in FIG. 6, time interval 
TO. 

In response to the execution of the interrupt instruc- 
tion, the processor 22, operating under control of the 
host operating system, invokes the system fault handler 65 
procedure, as shown in step 190. Upon invoking the 
system fault handler, a second frame is added to the user 
process stack. This frame, which is stored in volatile 



storage area 26, provides a temporary storage for all 
computations and process control actions taken by the 
system fault handler; see FIG. 6, time interval Tl. The 
new stack frame, the fault frame, includes a return pro- 
gram counter directed to the breakpoint instruction of 
the original user process. 

The system fault handler responds to execution of the 
debugger breakpoint instruction by calling the debug- 
ger start-up routine which, in turn, notifies the debug- 
ger 48, as shown in FIG, 4, element 192. Upon invoca- 
tion of the start-up routine, a third stack frame is added 
to the user process stack; see FIG. 6, Time Interval T3. 
As before, the new stack frame is used for per process 
calculations and flow control. Additionally, however, 
the new stack frame effectively serves as a communica- 
tions area for the debugger and the user process, partic- 
ularly with regard to execution of the simulated code. 

Upon invocation, the debugger start-up sequence 
stores in shared memory further information regarding 
the user process. The start-up sequence then issues a 
notify instruction to invoke the debugger process 49, 
while placing the user process in a suspended state. In 
the preferred, illustrated embodiment, the debugger 
process 49 is implemented as a separate, highest priority 
process within the PRIMOStm operating system. In 
this role, the host computer resources, including partic- 
ularly the system console and central processing unit, 
are uninterruptably dedicated to the debugger process. 
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Accordingly, the host computer, and specifically, the process fiow dontinues with the exemplary next mstruc- 

scheduling/exchange element, or dispatcher, is inhib- tion, "STA 2002". See FIG. 4, element 210. 

ited from scheduling further processes for execution. jy single Steps 

At the outset, the debugger process 49 maps in the ' , . . 
address space of the user process which executed the 3 In addition to permitting the setting of breakpoints at 
breakpoint; see FIG. 4, element 194. As shown by ele- specific locations within the user or operating system 
rnent 196, the debugger process 49 permit* access to code, the debugger 48 permits the operator to step 
values stored in the system's volatile memory 26. through the code one instruction at a time. For example, 
Through use of the debugger command structure, the if a particular section of code appears faulty, the opera- 
operator may effect the printing of selected ones of 10 tor may set an initial breakpoint to suspend execution at 
those values on the system console IX Additionally, the the beginning of the faulty sequence. Once the break- 
operator may change selected values in the volatile point is executed and control transferred to the debug- 
memory by entering, for example, new values on the get process 49, the operator may request that the debug- 
system console. Still further, the operator may set fur- ger process 49 enter single-step mode, thereby effec- 
ther breakpoints in operating system code, as well as 15 tively causing the processor to enter the debugger after 
placing the debugger in single-step mode. A document the execution of each subsequent instruction, 
detailing features of a preferred debugger is provided in In a debugger 48 constructed according to a pre- 
Appendix D (available in the application file history). ferred embodiment of the invention, single-stepping is 

Referring to element 19$, the debugger process 49 effected by repeatedly removing, after execution, each 

modifies the start-up frame to include the address of the 20 breakpoint, while setting a new breakpoint at the next 

code simulating the breakpointed instruction. See FIG. line of code. That is, once control is passed to the 

4, element 198; FIG. 6, time interval T4. The purpose of debugger process 49 in consequence to execution of a 

this operation is to force the user process to execute the breakpoint interrupt, the breakpointed instruction is 

simulated code, thereby simulating action that the reinstituted and a new breakpoint is set at the next in- 

breakpointed instruction would have taken bad it not 25 struction. In this manner, the breakpoint interrupt is 

been removed in favor of the interrupt instruction, transferred from line to line within the executed code. 

BRKFT. In a preferred embodiment, the simulated By way of example, referring to FIG. 5B and the 

code is executed by effecting a jump to the address discussion above, having received control after execu- 

where the simulated code is stored. As noted above, tion of the interrupt at address 4012, the debugger 48 

sample simulated code replacing the increment instruc- 30 effects single-stepping by first reinstituting the break- 

tion **A1A" is shown in FIG. 5C pointed instruction. This requires that the debugger 48 

Before returning control to the user process, the re- invoke the breakpoint module 42 for reinsertion of the 

turn program counter in the fault handler frame must be breakpointed instruction, eg., M A1A'\ at the address 

changed. As shown in FIG. 6, time interval TO, and in 4012. The debugger 48 then engages in a next instruc- 

FIG. SB, the debugger sequence was initiated upon the 35 tion prediction sequence to determine which instruction 

execution of the interrupt instruction, BRKFT, residing the user process will execute upon return from the 

at address 4012. Subsequent to execution of the simu- debugger. Upon making that prediction, the debugger 

lated code, and the "popping" of the startup and fault process 49 invokes the breakpoint routine 42 to request 

stack frames, it is essential that the user process continue the setting of a breakpoint at the next predicted instruc- 

through execution of the instruction following the inter- 40 tion. 

rupt Accordingly, as one of its fmal acts, the debugger More particularly, after permitting accessing and 

process 49 increments the return program counter in the modifying volatile storage with the debugger process 

fault stack frame to point to address 4014, the location 49, the debugger invokes the breakpoint element 42 to 

where the "STA 2002" instruction resides in accord reinstitute the originally breakpointed instruction, as 

with the exemplary code shown in FIG. 5B. 45 well as to set a breakpoint at the next predicted instruc- 

As shown by element 202, the debugger process sus- tion. The debugger process 49 then enters the sus- 
pends itself, thereby permitting other processes, includ- pended state, via execution of a wait instruction, and 
ing the breakpointed user process, to be scheduled for returns control to the user process for execution of that 
execution. reinstituted instruction. In the event that the original 

As indicated by FIG. 4, when the previously sus- 50 breakpoint was set by the user, and not the result of a 

pended user process regains access to the CPU, it imme- single-step, the debugger returns control to the next 

diately executes a jump to the simulated code; see ele- predicted instruction via execution of simulated code, as 

ment 204. Preferably, the final instruction of the simu- discussed above. 

lated code sequence is a procedure return, PRTN; see, A preferred sequence for next instruction prediction 
for example, the instruction stored at address 1036 of 55 for branch instructions is provided in FIG. 7, beginning 

instruction space 216 of FIG. 5C See also FIG. 4, ele- with element 218. At the outset, the prediction element 

ment 206. Execution of the return instruction effects examines the breakpointed instruction— that is, the in- 

removal of the start-up frame from the user stack. See struction whose replacement has resulted in current 

FIG. 6, time interval T5. invocation of the debugger. If the instruction is a branch 

Subsequently, the user process executes remaining 60 instruction, the debugger transfers control to step 220. 

portions of code provided in the fault handler sequence: At step 220, the debugger locates relevant portions of 
Preferably, this code itself merely invokes a procedure the user stack frame. Preferably, these portions include 
return, thereby popping the fault frame from the user the program counter and the registers, 

stack. See FIG. 4, element 208; and FIG. 6, time inter- As indicated in step 222, the prediction element cop- 

va l t& 65 ies the branch opcode directly into the next prediction 

Control having returned to the original frame, the code itself, 

user process continues execution with the instruction As indicated in step 224, the prediction element loads 
following the breakpoint interrupt Accordingly, the register values for locally simulating the state of the 
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user process. Where, for example, the branch instruc- 
tion requires a branch based upon the value stored in the 
A register, the debugger 48 loads the value copied from 
the user process stack frame into the current register. 

Subsequently, in step 226, the debugger ezecutes a 
copy of the branch instruction, utilizing for an operand 
the local address of illustrated instruction 232. 



16 



the breakpoint element 42 is invoked to set a breakpoint 
at address 4012. 

A preferred sequence executed by the debugger for 
next instruction prediction for branch instructions is 
shown below. Particularly, this sequence determines 
how flow control changes following a branch instruc- 
tion. 



NEXT_BRAN 



B RAN _ START 



DYNM 


- 112 


DYNM 


INSTX3) 


DYNM 


STRT_FRAME(3) 

] 


DYNM 


BRAN TEMPC2) 


BRA- 




N_S- 




TART- 





Reset stack. 



Instruction to relocate. 



Process startup suck frame. 



, INST, 
2 

ARGT 



(tnst, st rt_ frame) 
*Use the LB register to reference the process's startup stack frame. 
LDL STRT_FRAME, • 
STL BRAN_TEMP 
EALB BRAN_TEMP,* 
•Copy the branch instruction into this code. 

LDA INST,* 

STA BRAN INST 

•Simulate the state of the process by restoring it's registers. 

LDA LB%+ STARTUP FAULT_KEYS,* 

TAK 

RRST L B % + STARTUP RS A V_AR£A, * 

•Eiccute the actual branch instruction here. 
BRAN INST BSZ 1 

The branch instruction 
is put here. 

DAC BRAN_TARGET 

Branch address. 

•Branch was not taken. Next instruction is 1 more than the current pc. 

LDL LB% + STARTUP BRJCPT_ADDR 

ADL " »2L 
PRTN 

'Branch was taken. The word number of the branch address is the next instruction 
to execute within the current segment 
BRAN_TARGET LDL INST,* 

Word number from the branch. 

LDA LB96 + STARTUP BRKPT_AX>DR 

Segment from brkpt address. 

PRTN 



As indicated in step 228, where the local simulation 43 
does not result in a branch, flow control is passed to step 
230, while if the simulation does result in a branch, flow 
control is passed to step 232. There, the debugger iden- 
tifies the operand of the original branch instruction and 
retains that operand as indicative of the next predicted 50 
instruction. For example, if the operand of the replaced 
instruction indicated that the branch address was 8324, 
that value would be retained as the prediction address. 

Where flow control is transferred to step 230, the 
debugger predicts that user process flow control will 55 
not branch after execution of the replaced code. Ac- 
cordingly, the prediction element retains the incre- 
mented user stack frame program counter as the pre- 
dicted address. For example, if the program counter 
from the user stack frame is 4010 and no branch is pre- 60 
dieted, the prediction element will retain 4012 (i.e., 
4010+2) as the predicted address. 

In step 234, the debugger invokes the breakpoint 
element 42 to set a breakpoint at the predicted address 
of the next executed instruction. Thus, in the examples 65 
immediately above, where a branch has been predicted, 
the breakpoint element 42 is invoked to set a breakpoint 
at address 8324. While, if no branch has been predicted. 



Those skilled in the art will readily appreciate that 
the aforementioned sequence is similarly applicable to 
next instruction prediction for other flow control in- 
structions, e.g., skip instructions. 

A preferred software embodiment of next instruction 
prediction for other flow control instructions is pro- 
vided in Appendix C (available in the application file 
history) at pp. 360-367, 484-496, and 1039-1045. 

Described above is a preferred embodiment of a sys- 
tem for facilitating the isolation and correction of errors 
in instruction processing on a digital computer. While 
the illustrated system is particularly suited for use with 
multiprogrammable machines having embedded operat- 
ing systems and hardware controlled process exchange 
(e.g., systems of the type provided by prime Computer, 
Inc. Series 50 computers), the teachings provided 
herein will be recognized by those skilled in the art to 
have broad application. Further, skilled artisans will 
recognize that the aforementioned description of the 
illustrated embodiment is exemplary only; modification, 
addition, or deletions from that description does not 
detract from the scope of the invention described and 
claimed in this application for patent. 

Accordingly, what is claimed is: 
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1. A multiprograxnmable digital data processor com- 
prising: 

A. memory means having addressable locations for 
storing process code signals associated with each of 
one or more processes, wherein the process code 
signals associated with each process include signals 
representative of at least one of instructions, data, 
and state values of that process, 

B. breakpoint means coupled with the memory means 
for replacing therein a signal representative of a 
selected instruction with a selected interrupt signal, 

C. scheduler means for scheduling one of said pro- 
cesses for execution during a designated time inter- 
val, 

D. first centra] processing unit means coupled to the lJ 
memory means and to the scheduler means for 
normally executing the scheduled one of said pro- 
cesses during the designated time interval, 

E. debugger means coupled to the first central pro- 
cessing unit means for selectively 
L suspending processing of the scheduled process 

by the first central processing unit means, 
ii. permitting selective access to locations of said 
memory means for at least one of modifying and 
outputting values of signals stored in those ac- 
cessed locations, 

F. said debugger means further including simulation 
means for generating simulation code signals, rep- 



20 
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7. A multiprogrammable digital data processor ac- 
cording to claim 6, wherein said debugger means in* 
eludes means for modifying said first return code signal. 

8. A multiprogrammable digital data processor ac- 
cording to claim 6 further comprising start-up means 
coupled with said fault handling means and responsive 
to said start-up signal for generating a notify signal for 
initiating operation of said debugger means. 

9. A multiprogrammable digital data processor ac- 
cording to claim 8, wherein 

A. said memory means includes means for storing 
signals representative of instructions for execution 
by said start-up means, 

B. said start-up means is coupled to said memory 
means for executing those start-up instruction- 
representative signals, and 

C. said debug means includes means for modifying 
those start-up instruction-representative signals for 
including therein a signal representative of a loca- 
tion of said simulated code signals. 

10. A multiprogrammable digital data processor ac- 
cording to claim 1 wherein said debugger means com- 
prises single-step means coupled to said memory means 
for ^instituting said replaced instruction and for replac- 
ing a next executed instruction with said selected inter- 
rupt instruction* 

11. A multiprogrammable digital data processor ac- 
cording to claim 10 wherein said single-step means 



resentative instructions for simulating the selected w comprises next instruction prediction means for deter 



replaced instruction, and 
C. said debugger means further includes restart 
means for reactivating the suspended process for 
execution of at least said simulation code. 

2. A multiprogrammable digital data processor ac- 35 
cording to claim 1, wherein said simulation means in- 
cludes means coupled with said memory means for 
including said simulation code signals in the process 
code signals associated with the suspended process. 

3. A multiprogrammable digital data processor ac- 40 
cording to claim 1, wherein said debugger means in- 
cludes means coupled with said scheduler means for 
inhibiting the scheduling for execution of any of said 
other processes. 

4. A multiprogrammable digital data processor ac- 45 
cording to claim 3 wherein said restart means includes 
means for re-enabling said scheduler means to schedule 
for execution said other processes. 

5. A multiprogrammable digital data processor ac- 
cording to claim 1, wherein 50 

A. said memory means includes means for storing 
fault instructions including at least a start-up in- 
struction sequence, 

B. said first central processing unit means includes 
means for executing said selected interrupt signal 55 
for generating a selected fault signal, and wherein 
said digital data processor further comprises 

C. fault handler means coupled to said first central 
processing unit means and to said memory means, 
and responsive to said selected fault signal, for 60 
executing said start-up instruction sequence to gen- 
erate a start-up signal. 

6. A multiprogrammable digital data processor ac- 
cording to claim 5 wherein said fault handler means 
further comprises means for generating and storing a 65 
first return code signal representative of a location 
within said memory means of said selected interrupt 



mining a location within said memory means of said 
next executed instruction. 

12. A multiprogrammable digital data processor ac- 
cording to claim 11 wherein said next instruction pre- 
diction means includes means for simulating execution 
of the replaced instruction and for determining there- 
from the location of the next execute instruction. 

13. A multiprogrammable digital data processor ac- 
cording to claim 1, wherein 

A. said scheduler means includes means for schedul- 
ing a second one of said processes for execution 
during said designated time interval, said processor 
further including 

B. second central processing unit means coupled to 
the memory means and to the scheduler means for 
normally executing said second scheduled process 
during the designated time interval, and wherein 

C said debugger means is coupled to said second 
central processing unit means for selectively sus- 
pending processing of the second scheduled pro- 
cess by the second central processing unit means. 

14. A multiprogrammable digital data processor ac- 
cording to claim 1, wherein said memory means in- 
cludes 

A. resident memory means for storing for rapid ac- 
cess a first subset of said process mode signals, 

B. virtual memory means for storing for paged access 
a second subset of said process code signals, and 

G said breakpoint means includes means for generat- 
ing and storing in said resident memory means a 
virtual breakpoint signal indicative of a breakpoint 
in said second subset of process code signals. 

15. A multiprogrammable digital data processor ac- 
cording to claim 14, further comprising 

A. paging means for reading said second subset of 
process code signals into said main memory means, 
and for generating a paging signal indicative 
thereof, wherein said 
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B. first central processor unit means includes means G. generating simulation code signals representative 

selectively responsive to said paging signal for instructions for simulating the selected replaced 

executing said virtual memory breakpoint signal, instruction, and 

aad H. reactivating the suspended process for execution 

C said breakpoint means includes means responsive 5 of at least said simulation code. 

srgnal for ^^^^^^ m ^ a «^ comprising the step of including said simulation code 

representative of a selected instruction with a se- m the process code signals associated with the 

lected interrupt signal. suspended process, 

16. A multiprogrammable digital data processor com- ^ A mctnod of operating a multiprogrammable 
prising: digital data processor according to claim 17, further 

A. memory means having addressable locations for including the step of inhibiting the scheduling for exe- 
storing process code signals associated with each of cution of any of said other processes. 

one or more processes, wherein the process code 15 20. A method of operating a multiprogrammable 

signals associated with each process include signals digital data processor according to claim 19 further 

representative of at least one of instructions, data, including the step of re-enabling the scheduling for 

and state values of that process, execution of said other processes. 

B. breakpoint means coupled with the memory means 21. A method of operating a multiprogrammable 
for replacing therein a signal representative of a 2Q digital data processor according to claim 17, further 
selected instruction with a selected interrupt signal, comprising the steps of 

C scheduler means for scheduling one of said pro- A. providing in said first storage means at least a 

cesses for execution during a designated time inter- start-up instruction, 

val B. executing said selected interrupt signal for general- 

D. first central processing unit means coupled to the 25 ^8 a selected fcdt signal, 

memory means and to the scheduler means for C. responding to said selected fault sigiud for execut- 

nonnally executing the scheduled one of said pro- m «J d mstructlon t0 a start ' u P 

cesses during the designated time interval, 22^ A method of operating a multiprogrammable 

E. said memory means further includes means for ^ OCC8SOr to claim K 21 Uprising 
storing debugger process signals for placing said 30 ± XfMrthtt steps of generating and storing a first return 
first central processing unit in a debugging operat- code signa] rcprcscn tauve of a location within said first 
ing mode for selectively storage element of said selected interrupt signal. 

L suspending processing of the scheduled process 23. A method of operating a multiprogrammable 

by the first central processing unit means, digita | ^ processor according to claim 22, including 

ii. permitting selective access to locations of said 35 thc further step of modifying said first return code sig- 

memory means for at least one of modifying and ^ 

outputting values of signals stored in those ac- 24. A method of operating a multiprogrammable 

cessed locations, digital data processor according to claim 23 comprising 

F. said debugger means further including simulation the further step of responding to said start-up signal for 
means for generating simulation code signals repre- 40 generating a notify signal for initiating steps said afore- 
sentative instructions for simulating the selected mentioned steps (E) through (H). 

replaced instruction, and 25. A method of operating a multiprogrammable 

G. said debugger means further restart means for digital data processor according to claim 17 comprising 
reactivating the suspended process for execution of the further steps of reinstituting a replaced instruction 
at least said simulation code. 45 and replacing a next executed instruction with said 

17. A method of operating a multiprogrammable selected interrupt instruction. 

digital data processor, said method comprising the steps 26. A method of operating a multiprogrammable 

0 f digital data processor according to claim 25 wherein 

A. storing in a first storage element process code ^ said replacing step comprises a next bstruction predic- 

signals associated with each of one or more pro- 50 * on ste P for determining a location wi hm said first 

cesseZ wherein the process code signals associated ^^ clcm ^V? f ae * exccuted £ $tructl0n - M 

wifceach process include signals representative of * mcthod of \ mutoprogrammable 

at least one of instructions, data, andstate values of ^ V 10 ™* 50 ' * ch T ? 

« vu* v* u«m^««i«, said next instruction prediction steps includes the fur- 

tnat process, 55 ther step of simulating execution of the replaced instruc- 

B replacing in said first storage element a signal rep- don ^ fof j^^j^g therefrom the location of the 

resentative of a selected instruction with a selected next instruction. 

interrupt signal 28. A method of operating a multiprogrammable 

C scheduling one of said processes for execution digital data processor according to claim 17, comprising 

during a designated time interval, the further steps of 

D. executing the scheduled one of said processes A> scheduling a second one of said processes for exe- 
during the designated time interval, cution during said designated time interval, 

E. suspending processing of the scheduled process, b. executing said second scheduled process during 
and the designated time interval, 

F. permitting selective access to locations of said First 65 C. suspending processing of the second scheduled 
storage element for at least one of modifying and process by the second central processing unit 
outputting values of signals stored in those ac- means. 

cessed locations, * * * * * 
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